読みだしたtsファイルで緑色のノイズのような物が発生するのですが解決策はありますでしょうか?

その緑のノイズが特定の部分だけ発生して、他の部分では発生しないのなら、ソースファイルの
その緑になった部分が破損しているのだと思います。破損したファイルはもうどうしようも
ありません。

>fayさん
ファイル全体で発生します｡
BDから吸い出しているのですが､その元のBDでは発生しません｡
また読みだしたtsファイルをメディアプレーヤーで再生しても発生しません｡
このエンコーダーのみで出るのですがなにか原因は考えられますか?

>読みだしたtsファイルで緑色のノイズのような物が発生するのですが解決策はありますでしょうか?
初めまして。

私も同じ現象にあった事があります。私の場合、原因はメモリのハード障害でした（「Mem Test 86+」というメモリ診断フリー･ソフトで異常を発見し、新品メモリに交換した所、終息しました）。

二人目の方が言われている再エンコード対象動画ファイル自体の破損でも生じる現象ですが、そちらの方は質問者さんによる切り分け判断で問題無さそうなので、今度はメモリが健全か否か調べてみる事をお勧めします。

読みだしたtsファイルで緑色のノイズのような物が発生するのですが解決策はありますでしょうか?

タイトルの通り、音声の多重化について質問させて下さい。

現在MP4形式の動画（H.264、AAC音声）に別途、Wav形式の音声を
重ねて再生出来るように編集したいと思っています。
編集中の動画名を「A」、別途Wav音声ファイルがB～Eの4つあるとします。
この場合に、以下の事をする方法がわかりません。

Aの再生開始
　⇒10秒後の時点に音声B（再生時間5秒）を挿入
　⇒1分後の時点に音声C（再生時間10秒）を挿入
　⇒1分30秒の時点に音声D（再生時間10秒）を挿入
　⇒1分45秒の時点に音声E（再生時間5秒）を挿入

編集動画の音声と挿入する音声の形式が異なるから無理でしょうか？

どなたかご教示ください。

タイムライン編集でできると思うけど、どうだろう。

ご回答ありがとうございます。

タイムライン編集で思った通りの形ができました。

ありがとうございました。

マルチコアを使って、１つの動画をエンコードするときに、

動画を分割して同時にエンコードすれば高速にエンコード出来ると思うんですが・・

ソフトがインストしてあるマシンの

マザーボードとＣＰＵを交換したいのですが

交換するとこのソフトは使用不可になりますか？

ならないです。

現在表示ている画像を保存(B)をよくつかってるんだけど
現在表示ている画像のフレーム数をファイルネームにして
フィルター処理をしてJPGEかBMPで出力する
ていう機能がほしいです。

カット編集-フィルター-右クリック-B-ファイル名入力を
一発でやりたいです
ちなみにカット編集から始まってる理由は
時間/フレーム番号指定移動ができる
画面が大きい
からです

スピード変更フィルタを用いて字幕フィルタを使うと、完成した動画の字幕の開始時間と終了時間がずれます。

例）3分の動画に300％のスピード変更を適用し、Ａという字幕の開始時間を30秒に設定、終了時間を35秒に設定して動画をエンコードしますと、完成された動画内のＡという字幕が再生後10秒の場所に反映されてしまいます。

私が読み込んだ動画ファイルは1080　60ｐのAVCHDファイルです。
どなたか同様の現象が再現された方がいましたら、教えてくださると助かります。

バグじゃないでしょうか！多分まだアップデータで改善していないと思います。
フィルターを適応した後、一旦プロジェクトを保存して再度プロジェクトを開きエンコードしてみてはいかがでしょうか？

返信ありがとございます。

ペガシスに問い合わせたところ、ペガシスでも報告した現象が再現されたとのことですので、バグのようです。
次のアップデートを待つか、以前までは正常に作成できたので、5.3.1.85以前のバージョンを使用して作成しようと思います。

タイムラインモードで複数のクリップに一括でフィルター（リサイズやノイズフィルター）を適用するにはどうすればいいですか？

TMPEG5 で、モザイクをかけたいけど、なんていうか、使いにくいんだけど、
もっと便利に使うやりかたってあるんですか？

いま、ライムライン編集で、モザイクのレイヤーを出して
初期は、丸型、四角にかえて、幅、高さを％で設定。
個人名がみれる画面キャプチャ動画の名前を隠したいけど、出る前からかけたいけど、
なんていうか、こんなにやりにくいのありですか？
あてずっぽに、このへんかなって、はじめて。自動設定では、遅すぎたち早すぎたり、
一定の位置で固定して、やりたいけど、なんていうか使いにくい

TMPGEnc Video Mastering Works 5、Intel Media SDK hardwareエンコードで作成したmp4を読み込むことができません。仕様でしょうか？

どういうパラメーターでエンコードして、どういうものに読みこませようとしたのか。

わからなければ回答しようがない。

条件はよくわからないですがカット編集画面で
しばらく無操作にしていると画面がトーンダウンすると思います。

マウスカーソルを動かすとトーンアップしますが
このせいで画面が非常に見づらく編集作業がやりづらいです。

また、キーボードで編集しているとトーンアップすらされません。

トーンダウンをすること自体を止めるか
せめてキーボード操作でトーンアップするようにしていただけませんでしょうか。

パネル透過設定以外のことを言っているのであればPC（ノート？）の設定か外部の問題だと思いますよ。

カット編集画面でマウス右クリック＆ドラッグ操作で
プレビューを高速移動する際に画面端いっぱいまで
マウスカーソルを引っ張ると

全画面ウィンドウ表示で
右端まで引っ張る → 右三角１１個
左端まで引っ張る → 左三角１２．５個くらい

小さなウィンドウ表示にして
右端まで引っ張る → 右三角１９個
左端まで引っ張る → 左三角２４個

それぞれ実際に何倍速になっているのかはわかりませんが
全画面ウィンドウだと明らかに遅いです。

全画面でも最大速が出るように修正いただけませんでしょうか。

サムネイルを閉じてキーボード編集を行うとき
Ctrl+Shift+PgUp/PgDnやその他のキーは使えるのに
Shift+PgUp/PgDn，Ctrl+PgUp/PgDn，PgUp/PgDnキーだけ使えません。
使えるよう対応お願いします。

キーに割り当てられている動作が「xx%スクロール」になっているからじゃないかな。サムネイルを表示していない
状態ではスクロールといわれても出来ないんでしょう。私は時間/フレーム移動にしているので、サムネイル非表示
でも問題なく動作している。

fayさん情報有難うございます。
>キーに割り当てられている動作が「xx%スクロール」になっているからじゃないかな
確かにxx％スクロールに設定してますが
これに慣れると使い勝手と編集パフォーマンスが最も良くこれに対応してもらわ
ないと困ります。
しかし％スクロールではサムネイルを閉じると何故スクロールできない
のでしょうか？
再生を高速にするのと何ら変わりはないはずですしサムネイル表示だけオフに
する構造であればよいはずでしょう。
これができればサムネイルの表示パフォーマンス分を編集処理を更に高速に
できるとと期待しているのですが…

>しかし％スクロールではサムネイルを閉じると何故スクロールできない
のでしょうか？

高速スクロールがサムネイルを利用した機能だからではないでしょうか？
サムネイルon、offは表示するかしないかではなく機能を使うか切るかなのでしょう。

おっしゃる通り単に表示のon、offになれば動くようになりそうですが、内部で同様の
処理が行われるので期待したほどの改善はないかもしれません。

なんにしても結構大きな変更に感じますのであまり期待しないで待っているのが良いかも
しれませんね。

あれ、読み返すとちょっと紛らわしい表現になてますね。
正確には「サムネイルを高速にスクロールする機能」ですね。

>処理が行われるので期待したほどの改善はないかもしれません。
それでもサムネイルのサイズはメイン画面の何割かの表示領域と
先に表示すべきコマ数の画像枚数を展開した上で縮小処理して
貼り付けているはずでありそれと同時に表示すべきメインの表示も
行われているしサムネイルの枚数はストリングスデータと違い２次
元ですのでそのボリューム分の効果はそれなりになると思いますの
で期待してます。（＾＾）

また画像展開処理と表示処理が切り離せていなくてできないというのは
プログラム構造が悪いことを露呈しています。
TMSR4の方でも不具合として書き込んでいますが画像で展開と表示処理は
分けてもパフォーマンスダウンになることはありません。
できないというはやはりプログラム構造が悪いのです。
私は作り手でもありますのでその辺のバランスの悪さはこれまで使ってき
て想像がついています。

できるを見せていただきたいです！！

動画系のソフトは作っていないが、まあ一応末席にいる作り手が処理を推測してみた。
おそらく動作から見て処理は以下のようになっていると推測している。

1.サムネイルは縮小した結果だけをキャッシュしている
縮小キャッシュの根拠はメモリの消費量から導き出せる。
Process Hackerなどで観察することでメモリ消費量は確認できる。

2.サムネイル処理は再生とは別スレッドで行われていて、相互に通信していない
この根拠は大きくシークし、即再生を始めた時にサムネイルの生成は再生点とは関係ないところから行われており、再生された箇所のサムネイルは生成されない点から推測される。
この点からサムネイルとプレビューデコードのデータは共有していない。おそらく共有することによるリソースのロック競合による性能の低下を避けているのだろう。

3.サムネイル非表示のときにはサムネイル生成処理自体をオミットしている
サムネイルをオフにして、大きくシークし、しばらく待ってからサムネイル表示をした場合にサムネイルが生成される様子が見えることから、サムネイル表示をオフにしている時にはサムネイル生成をオミットし、レスポンスを向上させようとしていることが推測される。

私はこう推測したがどうだろう。